Traditionally, Internet Protocol (IP) allows hosts to communicate in a variety of ways. The most common schemes involve unicast communication (i.e., one host communicating with one client) and broadcast communication (i.e., one host communicating with all clients). A third scheme provided by IP is multicasting, where one host communicates with a group of clients.
In multicasting, message streams broken into packets are delivered to a group identified by a single multicast group address. The sender uses the multicast group address as the destination address of a datagram to send packets to all the members of the multicast group. Thus, using multicasting, any host can send packets to a group, and members of the group receive the packets. Multicasting allows one host to serve many clients, while sending the packets only once. Typically, multicast packets are User Datagram Protocol (UDP) packets.
A common use of multicast communication is for sending digital audio/video streams. When an audio/video stream is sent to a multicast address, multicast enabled routers forward the packets across any interface that has hosts or routers that have joined the associated multicast address. The one-to-many relationship between a single multicast stream source and the many clients allows efficient delivery of the audio/video stream.
Further, the packets containing the multicast media stream may be advertised to potential clients using Session Announcement Protocol (SAP). SAP packets, in turn, are used to deliver Session Description Protocol (SDP) messages. To announce a multicast session, the multicast source multicasts (i.e., sends packets using a multicast address) packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place. Clients that wish to know which sessions are going to be active simply listen to the same well-known multicast group, and receive those announcement packets. The content of the SAP and SDP message provides potential clients with information associated with the multicast source, the multicast address to receive the multicast stream (i.e., IP addressing information for “tuning into” the multicast message stream), and the content of the multicast stream. Specifically, an individual SAP packet contains the IP multicast address information for the session which it describes.
Trick-play, which includes the ability to pause, fast forward, rewind, etc., a video or audio stream, requires an originating source (i.e., the sender of the on-demand stream) to change the on-demand stream based on commands from the client receiving the packets. Using real-time streaming protocol (RTSP), a client informs the originating source to perform trick-play functions, and the originating source produces a separate unicast stream specifically for the requesting client. This causes an increased load on the originating source.
Typically, the client uses trick-play for on-demand audio/video streams (including multicast streams) using a client-side buffer to store the audio/video stream from the originating source and manipulate the stream on the client-side (i.e., rewind, pause, etc. and receive the manipulated stream from the client-side buffer). In some cases, providing additional client-side resources and increasing the complexity of the client device may cause the client device to become expensive.